REMARKS 



Applicants have studied tine Office Action dated IVlay 26, 201 1 and liave made 
amendments to tine claims. Claims 1-46, 49, 50, 54, 55, 57 and 58 were previously 
canceled without prejudice. Claims 47 and 52 have been amended. No new matter 
has been added as the amendments have support in the specification as originally filed. 
It is submitted that the application, as amended, is in condition for allowance. 
Reconsideration and is respectfully requested. 

Definition of Terms 

Prior to discussing the merits of the amended claims with respect to the prior art 
cited by the Examiner, Applicants respectfully define particular claim terms to clarify their 
meaning on the record. 

Applicants note that paragraph [0030] of the published specification (US 
2007/01 1 2932 A1 ) discloses that "the AV Transport service and the Rendering Control 
service are defined by the UPnP." "The UPnP, which is defined by a protocol of the 
standard network architecture, is one of the major standard technologies of the home 
network which a plurality of companies in each country create through the UPnP forum." 
See paragraph [0004] of the published specification. Therefore, Applicants submit that 
the terms "AV transport service," "transport state information," "rendering control 
service" and "rendering state information" as recited in the pending claims, are well- 
supported by the specification as originally filed, and defined by standardized 
specification documents of the UPnP. 

Regarding the claimed term "AV transport service," Applicants refer the 
Examiner's attention to the enclosed document titled UPnP AV Architecture:0.83, 
Contributing Members of the UPnP Forum, June 12, 2002 (hereinafter "UPnP 0.83"). 
Page 6, last full paragraph of UPnP 0.83 provides that AVTransport actions include 
actions such as "Stop, Pause, FF, REW, Skip, Scan, etc." Page 7, section 5.1.3 of 
UPnP 0.83 provides that AVTransport Service "is used by the Control Point to control 
the 'playback' of the content that is associated with the specified AVTransport. This 
includes the ability to Stop, Pause, Seek, etc." Page 8, section 5.2.3 of UPnP 0.83 
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further states that the AVTransport Service "is used by the Control Point to control the 
flow of the associated content" which "includes the ability to Play, Stop Pause, Seek, 
etc." Furthermore, page 5 of the enclosed document titled AVTransport:1 Service 
Template Version 1 .01 , Contributing Members of the UPnP Forum, June 25, 2002 
(hereinafter "AVTransport:1 1 .01 ") states that the AVTransport service "enables control 
over the transport of audio and video streams." 

Regarding the claimed term "transport state information," Applicants refer the 
Examiner's attention to AVTransport:1 1 .01 . Page 6 of AVTransport:1 1 .01 provides a 
table of state variables associated with the AVTransport Service (see Table 1 ). The first 
entry of Table 1 includes the state variable TransportState. Page 7 of AVTransport:1 
1 .01 provides a table of allowed values for TransportState (see Table 1.1). The allowed 
values identified for TransportState in Table 1.1 include STOPPED, PLAYING, 
TRANSITIONING, PAUSED_PLAYBACK, PAUSED_RECORDING, RECORDING and 
NO_MEDIA_PRESENT. Additionally, page 10, section 2.2.1 of AVTransport:1 1.01 
states that the state variable TransportState "forms the 'core' of the AVTransport service" 
and "defines the conceptually 'top-level' state of the transport, e.g., whether it is playing, 
recording, etc." 

In view of the descriptions found in the UPnP standardized specification 
documents, one of ordinary skill in the art would know that the term "AV transport 
service" as recited in the pending claims refers to a service for controlling playback of 
content associated with a specified AVTransport action such as Play, Stop, Pause, 
Seek, FF, REW, Skip, Scan, etc. Moreover, based on the descriptions found in the 
UPnP standardized specification documents, one of ordinary skill in the art would know 
that the term "transport state information" as recited in the pending claims refers to a 
flow status of transported media, such as stopped, playing, transitioning, paused 
playback, paused recording, recording or no media present, for example. 

Regarding the claimed term "rendering control service," Applicants refer the 
Examiner's attention to UPnP 0.83. Page 6, last full paragraph of UPnP 0.83 provides 
that a "Control Point is also able to control the various rendering characteristics on the 
Renderer device such as Brightness, Contrast, Volume, Balance, etc." Page 8, section 
5.2.1 of UPnP 0.83 provides that RenderingControlService "provides a set of actions 
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that allow the Control Point to control how the Renderer renders a piece of incoming 
content" which "includes rendering characteristics such as Brightness, Contrast, 
Volume, Mute, etc." 

Furthermore, page 6 of the enclosed document titled RenderingControl:1 Service 
Template Version 1 .01 , Contributing Members of the UPnP Forum, June 25, 2002 
(hereinafter "RenderingControl:1 1 .01 ") explains that "rendering devices contain a 
number of dynamically configurable attributes that affect how the current content is 
rendered" (see section 1.1). It also states that "video rendering devices, such as TVs, 
allows user control of display characteristics such as brightness and contrast, whereas 
audio rendering devices allow control of audio characteristics such as volume, balance, 
equalizer settings, etc." Therefore, the RenderingControl service "is intended to provide 
Control Points with the ability to query and/or adjust any rendering attribute that the 
device supports." See page 6, section 1.1 of RenderingControl :1 1.01. 

Regarding the claimed term "rendering state information," Applicants refer the 
Examiner's attention to RenderingControl :1 1 .01 . Pages 7-8 of RenderingControl :1 
1 .01 provides a table of state variables associated with the RenderingControl Service 
(see Table 1 ). Entries in Table 1 include the state variables Brightness, Contrast, 
Sharpness, Volume, etc. Applicants further note that Table 1 allows for a minimum 
value and a maximum value of a state variable to be identified. 

In view of the descriptions found in the UPnP standardized specification 
documents, one of ordinary skill in the art would know that the term "rendering control 
service" as recited in the pending claims refers to a service for controlling a dynamically 
configurable video and/or audio characteristic of the playing device such as brightness, 
contrast, sharpness or volume, for example. Moreover, based on the descriptions found 
in the UPnP standardized specification documents, one of ordinary skill in the art would 
know that the term "rendering state information" as recited in the pending claims refers 
to a video and/or audio characteristic value of the playing device, such as a brightness 
value, contrast value, sharpness value, or volume value of the playing device used for 
rendering content at the playing device. 

Applicants further wish to clarify the definition of the term "render" and its various 
forms (e.g. "rendering," "rendered," etc.) as may be recited in the pending claims above 
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and the remarks below. Page 5, section 5, first full paragraph of UPnP 0.83 provides 
that "[t]he most common task that end-users want to perform is to render (i.e. play) 
individual items of content on a specific rendering device." Page 5, section 5, second 
full paragraph of UPnP 0.83 further provides that "the MediaServer contains 
(entertainment) content that the user wants to render (e.g. display or listen to) on the 
MediaRenderer." Therefore, according to the description found in UPnP 0.83, the term 
"render" means to play, display or listen to content. 

Applicants further note that the meaning of the term "rendering" with respect to 
the present application is different from the meaning of the term "rendering state 
information" or "rendering state." In view of the explanation above, the term "rendering" 
is related to playing, displaying or listening to content, whereas the term "rendering state 
information" or "rendering state" is related to a video and/or audio characteristic value of 
the playing device, such as a brightness value, contrast value, sharpness value, or 
volume value of the playing device used for rendering content at the playing device. 

Rejections under 35 U.S.C. § 1 1 2 

Claims 47 and 52 were rejected under 35 U.S.C. § 112, first paragraph, as failing 
to comply with the written description requirement. This rejection is respectfully 
traversed. 

On pages 7-9 of the Office Action, the Examiner asserts that claimed features 
related to a "volume value" are not supported in the specification. Applicants 
respectfully disagree. Nonetheless, to expedite prosecution of the present application, 
the term "volume value" has been deleted from the claims. Moreover, Applicants note 
that in some instances, features related to a "volume value" have been amended to 
relate to a "video and/or characteristic value of the playing device." Support for the 
amended limitations can be found, for example, in paragraphs [0031] to [0033] and 
FIGS. 2-3 of the published specification (US 2007/01 12932 A1), and in view of the 
discussion above under the heading Definition of Terms . 

On pages 7-8 of the Office Action, the Examiner asserts that the feature "wherein 
transport state information is associated with a streaming status of the media content 
and is used by an audio/video (AV) transport service" is not supported in the 
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specification. The Examiner further states that the disclosure is silent on defining the 
AVTransport status as a "streaming status." With this paper, the noted feature has 
been amended to now recite "wherein transport state information is associated with an 
audio/video (AV) transport service and the AV transport service is used for controlling a 
transport flow of the media content." Applicants respectfully submit that the 
specification well supports the amended limitation in view of the discussion above under 
the heading Definition of Terms . 

On pages 8-9 of the Office Action, the Examiner asserts that the feature 
"according to the set rendering state information such that the playing device renders 
the streamed media content using the stored volume value transmitted from the server" 
is not supported in the specification. With this paper, the noted feature has been 
amended to now recite "according to the set rendering state information such that the 
playing device renders the transported media content using the video and/or audio 
characteristic value of the playing device included in the rendering state information." 
Applicants submit that the amended feature complies with the written description 
requirement. 

In view of the foregoing, it is respectfully submitted that claims 47 and 52 
overcome the rejection under 35 U.S.C. § 1 12, first paragraph. 

Reiections under 35 U.S.C. S 103 

Claims 47, 48, 51-53 and 56 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable over US 2004/0243700 A1 to Weast (hereinafter "Weast") in view of US 
2003/0046338 A1 to Runkis (hereinafter "Runkis"). This rejection is respectfully 
traversed. 

As amended, independent claim 47 has been clarified to include the following 
features: 

a) matching a protocol and a data format between the server and the playing 
device, the server and the playing device configured in the pull mode; 

b) requesting the playing device matched with the server in the protocol and 
the data format to receive and render media content streamed from the server, wherein 
transport state information is associated with an audio/video (AV) transport service and 
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the AV transport service is used for controlling a transport flow of the media content, 
wherein rendering state information is associated with a rendering control service and 
the rendering control service is used for controlling a dynamically configurable video 
and/or audio characteristic of the playing device, and wherein when the server and the 
playing device are configured in the pull mode, both the AV transport service and the 
rendering control service are executed by the playing device; 

c) transmitting, when playback of the media content bv the playing device is 
paused , a request to the playing device to transmit the transport state information and 
the rendering state information, the transport state information including a transport flow 
status of the media content at the time of pausing the media content, and the rendering 
state information including a video and/or audio characteristic value of the playing 
device at the time of pausing the media content : 

d) requesting the server to store in the server , the transport state information 
transmitted from the playing device to the at least one control device, and the rendering 
state information including the video and/or audio characteristic value of the playing 
device transmitted from the playing device to the at least one control device , wherein 
the at least one control device performs a resuming playback operation from a paused 
part of the paused media content when playback of the paused media content is 
resumed by the playing device; 

e) wherein the resuming playback operation comprises: receiving the stored 
transport state information and the stored rendering state information from the server, 
transmitting a first command including the stored transport state information received 
from the server to the playing device to set the playing device with the stored transport 
state information included in the first command, transmitting a second command 
including the stored rendering state information received from the server to the playing 
device to set the playing device with the stored rendering state information included in 
the second command; and 

f) wherein the media content is transported from the server to the playing 
device according to the set transport state information such that the media content is 
transported from the paused part of the media content indicated by the transport flow 
status included in the transport state information and is rendered in the playing device 
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according to the set rendering state information such that the playing device renders the 
transported media content using the video and/or audio characteristic value of the 
plavinq device included in the rendering state information . 

Amended independent claim 52 recites similar features. 

The Examiner asserts that Weast teaches or suggests various features of the 
claimed invention. In particular, on page 12 of the Office Action, the Examiner asserts 
that Weast discloses the claimed feature "requesting the server to store in the 
server... the rendering state information including the volume value transmitted from the 
playing device to the at least one control device." On page 3 of the Office Action, the 
Examiner also comments: "It is well known in the art that all media is recorded and 
stored at a certain volume level and the louder or softer the recording, the louder or 
softer the playback unless some sort of clipping or compression is applied during 
playback. Therefore the media content always has a volume value stored with it." 
Applicants provide the following remarks. 

With this paper. Applicants have amended independent claim 47 to recite 
"requesting the server to store in the server... the rendering state information including 
the video and/or audio characteristic value of the plavinq device transmitted from the 
playing device to the at least one control device" (emphasis added). Applicants note 
that the video and/or audio characteristic value of the playing device is a value of the 
playing device at a time when playback of the media content at the playing device is 
paused (see claim 47 and item c) above). Independent claim 52 has been similarly 
amended. 

Applicants respectfully submit that Weast does not disclose the amended claim 
feature. With regard to the disclosure of Weast and the Examiner's comments on page 
3 of the Office Action, Applicants respectfully submit that there is a distinction between a 
volume value of media content as may be taught by Weast and which the Examiner 
asserts is always stored with the media content, and a video and/or audio characteristic 
value of a plaving device , which is stored in a server when media content previously 
rendered at the playing device is paused, as required by the amended claims. The 
distinction lies in that the volume value of media content is a characteristic value of 
media content (Weast), whereas the video and/or audio characteristic value of the 
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claimed invention is a characteristic value of a playing device. 

Accordingly, in view of the above discussion, it is respectfully submitted that 
Weast fails to teach the following recited features of claim 47: "requesting the server to 
store in the server... the rendering state information including the video and/or audio 
characteristic value of the playing device," "transmitting a second command including 
the stored rendering state information received from the server to the playing device to 
set the playing device with the stored rendering state information included in the second 
command," and "wherein the media content... is rendered in the playing device 
according to the set rendering state information such that the playing device renders the 
transported media content using the video and/or audio characteristic value of the 
playing device included in the rendering state information." Applicants also submit that 
Weast fails to disclose similarly recited features in claim 52. 

Applicants further submit that Runkis fails to cure the above-identifed deficiencies 
of Weast. On pages 14-1 5 of the Office Action, the Examiner states that paragraph 
[0078] Runkis discloses the user requesting to continue playback of a movie which 
includes the rendering state of where the user stopped watching previously and data 
content control of where to restart the audio and video playback content services, the 
resumption information being audio and visual characteristics of playback . Paragraph 
[0078] of Runkis states: "a transient user can start watching a feature movie in one 
service zone, e.g. on a flight from New York to Chicago, pause the movie when the 
plane arrives at the airport in Chicago, change planes, and continue watching the 
movie, from the point that at which it was interrupted , on a different plane or even a 
different airline during the continuing flight, e.g. to San Francisco" (emphasis added). 

However, as clarified in the amended independent claims, the stored rendering 
state information includes a video and/or audio characteristic value of the playing 
device , wherein the video and/or audio characteristic value of the playing device is 
stored in the server when playback of the media content is paused at the playing 
device. Thus, although Runkis may disclose a state where the user stops watching 
content previously and data content control of where to start the audio and video 
playback, Applicants submit that in view of the amended claim, and the definition 
provided above for the term "rendering state information," Runkis' disclosure does not 
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teach or suggest storing rendering state information including a video and/or audio 
characteristic value of the playing device in the server when playback of the media 
content is paused at the playing device, as required by the amended independent 

claims. 

In view of the foregoing, it is respectfully submitted that claims 47 and 52, and 
the claims respectively dependent thereon, are allowable over the combination of Weast 
and Runkis. 

CONCLUSION 

In light of the above remarks. Applicants submit that the present Amendment 
places all claims of the present application in condition for allowance. Reconsideration 
of the application is requested. 

If for any reason the Examiner finds the application other than in condition for 
allowance, the Examiner is requested to call the undersigned attorney at the Los 
Angeles, California, telephone number (213) 623-2221 to discuss the steps necessary 
for placing the application in condition for allowance. 

Respectfully submitted, 

Lee, Hong, Degerman, Kang & Waimey 



Date: Augusts, 2011 By: /Lew Edward V. Macapaaal/ 

Lew Edward V. Macapagal 
Registration No. 55,416 

Customer No. 035884 Attorney for Applicant(s) 
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